“Presence” is well known in the telecommunications industry. Presence and presence information relate to a person having multiple devices with multiple communication paths and a user's preference or preferred device of availability. “Presence information” typically refers to any information associated with a network node and/or endpoint device, such as a communications device, that is in turn typically associated with a person or entity. Examples of presence information include registration information under the Session Initiation Protocol (SIP), information regarding the accessibility of the endpoint device, the endpoint(s) telephone number or address, the recency of use of the endpoint device by the person, recency of authentication by the person to a network component, and the preferences of the user, such as contact mode preferences or profiles. Presence information can be user configurable, i.e., the user can configure the number and type of communication and message devices (endpoints) with which they can be contacted and define profiles that govern the communication and message options presented to the incoming contact or in specified factual situations or sets of facts. By identifying a pre-defined set of facts, a profile can be accessed and followed to direct the contact to the user/preferred device.
Typically, presence information is communicated and updated via one or more messages exchanged, for example, between one or more endpoints and/or one or more servers. In calculating a presence for one or more endpoints and/or entities, a presence server may collect presence information from a number of sources. Among these sources, the presence server may collect presence information from calendar servers, email servers, as well as server applications.
Calendar applications can be used to schedule meetings or other types of calendar events along with a time-specific context. In addition, these meetings, or events, may be associated with a selected state of the user (e.g., Busy, Free, Tentative, Out-of-Office, etc). For example, a user may be invited to attend an important meeting, which, when accepted may alter the user's associated state (e.g., to Busy, Out-of-Office, Free, etc.) for the scheduled time of the meeting. In another example, a user may block out periods of time in a calendar application to reserve “Free” or “Busy” periods of time that may be used to alter future invitations and/or scheduling. In any event, the presence server can collect this calendar information associated with the user to calculate a presence associated with an endpoint and/or entity via a presence aggregation algorithm. Along with the calendar information, the presence server may collect email information to determine presence.
Email applications can be used to determine a user's availability and/or activity. For instance, email applications can include an “Out-of-Office” utility to notify others that a user may be “Out-of-Office” when an email is received by the user. The presence server can collect the email information to determine presence for an endpoint and/or entity. However, in calculating the presence for an individual who is associated with a number of endpoints, the presence server must consider a number of sources, states, and contexts, especially in the collection of information. In other words, all of the sources are treated as unique and are calculated accordingly. In some cases the presence sources may be associated with a priority that can be used to affect a resultant presence calculation. As can be expected, the algorithms applied in calculating presence for all of the individuals in an organization, group, enterprise, or network can be processor intensive and time consuming.